Aspects of embodiments of the present invention relate to the field of computer security, and, more specifically, protection against code injection attacks.
FIG. 1 is a schematic diagram of a typical computer system. In a typical computer system, a central processing unit (CPU) 10 includes a program counter (PC) 12, a plurality of registers 14, an arithmetic/logic unit (ALU) 16, and a bus interface 18. The program counter 12 provides the address of the next instruction to be executed, the registers 14 store data and values currently being computed, and the ALU 16 performs computations on the data stored in the registers 14. Data is transferred into and out of the CPU 10 via the bus interface 18, which interfaces with an I/O bridge 20 to communicate with main memory 30 and other peripheral devices 40. While FIG. 1 illustrates one typical computer system, various other typical computer systems may be organized in different ways (for example, the I/O bridge 20 may be integrated into the CPU 10, or the CPU 10 may include memory caches).
FIG. 2 is a schematic diagram illustrating a stack smashing buffer overflow attack. C. Cowan, et al., StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks 7 PROC. OF USENIX SEC. SYMP. (1998). As seen in FIG. 2, the stack 100 is stored in main memory 30 and grows in a downward direction (e.g., away from 0xFFFF and toward 0x0000). When a function call is made, a “Return Address” is pushed onto the stack and space is allocated for local variables, including a potentially attackable buffer at lower addresses. When input data is stored in the buffer, the data (e.g., a text string from user input) grows in an upward direction (with increasing addresses). If the size of the input data exceeds the allocated size of the buffer, data located at higher addresses than the buffer can be overwritten with the supplied data. In FIG. 2, for example, the data overflowing the buffer could overwrite the Local Variables, the return address, and portions of the stack above the return address (which is generally the portion of the stack allocated to the calling function).
As seen in FIG. 2, the overflowing buffer can be used to insert executable attack code into the stack and to overwrite the return address with a pointer to the attack code. As such, when the attacked function exits, the processor jumps to and executes the attack code instead of the function that it was called from. The attack code can be used to gain root (or administrator) access to the machine by, for example, executing the command ‘exec(“sh”)’ to produce a root shell.
Generally, stack-based code injection attacks require: knowledge of the instruction set of the underlying architecture; knowledge of the location of one or more buffers on the stack; ability to inject code/data; and ability to redirect the control flow. An attacker can use the stack to return to the injected or other arbitrary code.
In a homogeneous system (or homogenous portion of a heterogeneous system) it is easy for an attacker to craft a suitable machine code attack payload because the underlying instruction set architecture is known. Increasing the hardware diversity of a system can mitigate or overcome this problem, but this is not always a feasible option due to cost (e.g., the cost of duplicating hardware) or environmental constraints of the system in question. For example, weight or space constraints on an aircraft can limit the ability to add additional processing elements.
One existing technology to obfuscate the underlying instruction set is the use of Instruction Set Randomization (ISR). ISR randomizes the instructions in memory and then decodes the instructions before execution. This is effective in temporarily obscuring the underlying architecture, but, if the randomization value is discovered, a new attack can be crafted and injected. See, for example, Gaurav S. Kc, Angelos D. Keromytis, and Vassilis Prevelakis. Countering Code-Injection Attacks With Instruction-Set Randomization. 10 ACM CONF. ON COMP. AND COMM. SEC. PROC. 272 (2003) and see Elena Gabriela Barrantes, et al. Randomized Instruction Set Emulation. 8.1 ACM TRANSACTIONS ON INFO. AND SYS. SEC. (TISSEC) 3 (2005).